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(57) Abstract 

A method and system for providing to 
commercial market participants a dedicated 
data processor for consolidating and expe- 
diting a financial settlement system. Upon 
the placement of a commercial transaction 
order, all of the various transaction doc- 
uments such as the purchase order, con- 
firmation order, invoice and bill of lading 
are transmitted to the data processor of the 
present invention in electronic format and 
stored in a suitable database. Following de- 
livery of the goods to the Buyer, the Car- 
rier generates a proof of delivery which is 
thereafter forwarded to the data processor 
of the present invention. The various pieces 
of transaction information are then audited 
and reconciled by the data processor of all 
transaction documents, thus facilitating the 
resolution of possible exceptions which may 
prevent timely payment. The collection of 
information may also be processed by the 
present invention to provide accurate scor- 
ing of financial risk to a financial institution. 
This risk may be calculated based upon in- 
dividual transactions as well as transaction 
history between a Buyer and Seller. 
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WO 00/48053 PCT/USOO/02508 
COMMERCIAL TRANSACTION MANAGEMENT SYSTEM AND METHOD 



CROSS REFERENCE TO RELATED APPLICATION 

This application claims the benefit of provisional patent application Serial No. 
5 60/1 19,853 filed February 12, 1999, the disclosure of which is incorporated herein by 
reference. 

FIELD OF THE INVENTION 

The present invention generally relates to the field of commercial transactions, 
and more particularly, to an improved commercial transaction management system for 
10 streamlining operation, reducing costs, and achieving higher control of the entire 

commercial transaction settlement process via a dedicated electronic data processor 
over a computer network. 

BACKGROUND OF THE INVENTION 

1 5 Business to business commercial transactions for goods and services account 

for a significant portion of commerce in the United States and worldwide. 
Traditionally, such commercial transactions involve multiple parties including a buyer 
of goods or services, a seller of good or services, and, as necessary, a carrier of goods. 
In the course of such a commercial transaction, it is necessary to transfer a variety of 

20 physical documents between the various parties, many of which include redundant 

information. As a result of the generation and transfer of these physical documents, a 
multitude of possible inaccuracies can occur. In fact, by some estimates, 20% of all 
commercial transactions are affected by errors in the documents used to carry out the 
transaction. This results in the rejection of the initial invoice demand for financial 

25 settlement. 

In general, a Buyer issues a purchase order (PO) for a particular quantity of 
product to a Seller. The Seller, upon receipt of the PO may issue a confirmation order 
(CO) to the Buyer, indicating its acceptance of the PO and detailing such information 
as product availability, delivery, pricing, etc. The Seller then fulfills the order. The 

30 Seller then creates a bill of lading (BL) that includes a brief description of the goods 
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being shipped and the pertinent freight classification. The Seller creates and delivers 
independently to the Buyer an invoice (INV) that is the demand for financial 
settlement from the Buyer. The Seller then tenders the shipment, including a copy of 
the BL, to the Carrier for delivery to the Buyer or Buyer's designated receiver. The 
5 Carrier delivers the goods to the Buyer, and receives a signed acceptance from the 
Buyer, which forms a proof of delivery (POD) document that is returned by the 
Carrier to the Seller to confirm delivery of the goods. 

In addition to the documents discussed above, various additional documents 
may be generated during the course of the commercial transaction. For example, the 

10 Seller will often generate a Pick & Pack Manifest that details the line item contents of 
the shipment. An advance shipping notification (ASN) can be generated by the Seller 
to notify the Buyer that the goods will be shipped on or around a certain time to allow 
the Buyer to plan for receipt and processing of the goods. Additional documents may 
be generated in connection with the transaction for internal use by the Buyer, Seller or 

1 5 Carrier. For example, a sales order containing information similar to that in the PO 
can be internally generated by the Seller for internal documentation. The Buyer may 
also generate a receiving ticket (RT) in connection with receipt of the goods, which is 
used by the Buyer in reconciling the transaction. 

Upon submission of an Invoice to the Buyer, the Seller opens an account 

20 receivable for the goods transferred to the buyer. Furthermore, prior to payment and 
independent of the Seller, the Buyer begins an internal auditing, or reconciliation, 
process with respect to the received goods. During this process, the Buyer confirms 
that the transaction was conducted as expected in that the goods actually received (as 
evidenced in the POD or receiving ticket) conform to the goods requested in the PO. 

25 If the transaction is reconciled (i.e. the Buyer confirms that the goods expected were 
received), the Buyer confirms that payment should be made and closes the open 
account payable file that was created by the Buyer upon generation and submission of 
the original PO , which ultimately leads to payment to the Seller for the goods. 

If the Buyer fails to reconcile the transaction, however, an account payable 

30 will remain open and the Seller will not be paid until such time as the Buyer is 
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satisfied with the transaction. That is, for example, if the description of the goods in 

the original PO does not match with the description on the invoice; or if the Buyer 

requested a quantity of 100 in the PO, but only received 90 as evidenced in the POD, 

the Buyer will withhold payment until this discrepancy is resolved. Often, resolution 

5 of such a discrepancy is delayed until the Seller, recognizing that payment has not 

been made for the goods, contacts the Seller to request payment. Under traditional 

payment terms, this delay can be 30 days or more. Thus, despite the fact that the 

Buyer may recognize a discrepancy that will delay payment relatively early in the 

process, it may not be addressed until lack of payment is raised by the Seller 30 days 

10 or more later. 

As the complexity and size of today's global marketplace continues to grow, it 
is becoming increasingly more important for businesses to develop new and 
innovative means by which to increase the efficiency and cost effectiveness of 
conducting business. The above-described process is very complex and includes 

15 significant room for error, often through clerical errors in preparing the various 

documents or physical loss of the documents themselves. Further, the process is very 
lengthy typically taking from 30 to 90 days to complete. 

One known method for improving the efficiency of the commercial transaction 
process is to generate and transfer the various documents in electronic form, thereby 

20 reducing the time taken to transmit such documents. For example, U.S. Patent No. 
5,758,327 to Gardner et al. discloses an electronic requisition and authorization 
process wherein a central computer system connects a variety of supply chain parties 
including a vendor, various requisitioning companies, and a financial entity. The 
requisitioning companies can forward an electronic requisition form to the central 

25 computer, which is thereafter authorized in accordance with the requisition rules of 
the company. The central computer then forwards the requisition to an appropriate 
vendor, where the order is filled. A distribution provider delivers the items to the 
company and transmits an electronic proof of delivery to the central computer system. 
The vendor may transmit an invoice to the operators of the central computer system. 

30 The invoice from the vendor is matched with the electronic proof of delivery and if 
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the information matches, an invoice is generated by the central computer system and 
electronically transmitted to the company. 

Gardner, however, fails to disclose a system and method for reconciling a 
commercial transaction to verify the integrity of the transaction. As understood by 
5 those of skill in the art, the proof of delivery merely evidences that delivery of a 
certain shipment has been made with or without exception, and does not provide 
information necessary in validate and verify the information contained in the invoice 
received from the vendor. Thus, the system and method of Gardner merely substitutes 
electronic communications for the physical paper based communications previously 

10 used in the commercial transaction process. 

Another example of a computerized commerce system is disclosed in U.S. 
Patent No. 4,799,156 to Shavit et al. Shavit et al. discloses a system for interactive 
on-line electronic communications and processing of business transaction between at 
least a plurality of sellers, buyers, financial institutions and freight service providers. 

1 5 Like Gardner, however, Shavit et al. fails to disclose a system and method for 

reconciling a commercial transaction to verify the integrity of the transaction and 
merely substitutes electronic communications for the physical paper based 
communications previously used in the commercial transaction process. 
Although conversion of business documents from traditional paper copies to 

20 electronically transmittable documents reduces the cost and time taken to conduct 
business transactions, there remains a need for an improved business system that 
enables market participants to more quickly, accurately, and efficiently identify 
discrepancies in the various commerce transactions documents that prevent or delay 
financial settlement and better manage cash and credit settlement between various 

25 documents, transactions, and parties. There further remains a need for providing 
value added services to the commercial transaction market. 

SUMMARY OF THE INVENTION 

It is an object of the present invention to provide a system and method for 
30 overcoming the deficiencies noted above. 
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It is a further object of the present invention to provide an improved 
commercial transaction management system for streamlining operation, reducing 
costs, and achieving higher control of the entire commercial transaction settlement 
process via a dedicated electronic data processor over a computer network. 
5 It is another object to provide an electronic data processing system and method 

that captures commercial transaction information from one or more parties to the 
commercial transaction. 

It is a further object of the present invention to provide such an electronic data 
processing system and method that receives commercial transaction information, 
1 0 preferably in electronic form, from at least one of a Buyer, Seller and Carrier involved 
in a commercial transaction. 

It is yet another object to provide such a system and method wherein 
commercial transaction information is forwarded in electronic form from a Buyer, 
Seller or Carrier using a software agent resident on an ERP system of the Buyer, 
15 Seller or Carrier. 

It is an object of the present invention to provide a system and method to 
accelerate payment to a Seller for goods or services provided to a Buyer. 

It is a still further object of the present invention to provide such a system and 
method that reconciles the commercial transaction information to facilitate settlement 
20 of the commercial transaction, to validate the integrity of a receivable resulting from 
the commercial transaction, to facilitate payment to the parties of the commercial 
transaction, and/or to facilitate factoring or securitization of a receivable resulting 
from the transaction. 

It is another object to provide such an electronic data processing system and 
25 method wherein electronic data communication (such as an EDI connection, an 
Internet based connection, a LAN, WAN, VPN or other network connection, or a 
dedicate data connection) is provided between at least one of a Buyer, Seller and 
Carrier involved in a commercial transaction to facilitate transfer of the commercial 
transaction information to the data processing system. 
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It is yet another object of the present invention to provide a electronic data 
processing system and method to provide real-time or near real-time information on 
the status of a commercial transaction. 

It is an object of the present invention to provide a system and method for 
5 accelerating the resolution of disputes in a commercial transaction. 

It is a further object of the present invention to provide a system and method 
for decreasing the time necessary to settle a commercial transaction at least by 
facilitating reconciliation of data generated in connection with the commercial 
transaction and by facilitating resolution resolving disputes arising during the 
10 transaction. 

It is yet a further object of the present invention to provide a system and 
method for detecting inconsistencies in commercial transaction documents at the 
earliest possible time to facilitate reconciliation of, and dispute resolution in, the 
commercial transaction. 
15 It is yet another object of the present invention to consolidate information 

relating to a commercial transaction from several parties to the transaction in a central 
electronic data processing system. 

It is an object of the present invention to reduce or eliminate errors and 
inconsistencies between commercial transaction records of parties to a commercial 
20 transaction to facilitate settlement of the commercial transaction. 

It is yet another object of the present invention to identify suspect receivables 
early in the commercial transaction process to facilitate resolution of any disputes 
concerning the receivable, thereby reducing the risk that payment for the receivable 
will be delayed. 

25 It is an object of the present invention to increase the value associated with a 

receivable by reducing the risk that the receivable will be subject to dispute. 

It is a still further object of the present invention to increase the marketability 
of a receivable to a financial institution for use in securitization or factoring of the 
receivable. 
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It is an object of the present invention to increase the confidence that a 
receivable will be timely paid in accordance with the terms and conditions of a 
commercial transaction, thereby increasing the value of the receivable for use in 
securitization or factoring. 
5 It is another object of the present invention to provide a system and method 

permitting a Seller of a good or service to validate a receivable by continuously 
reconciling commercial transaction information throughout the commercial 
transaction process and upon receipt of a POD from a Carrier. 

It is an object of the present invention to provide a system and method that 
10 permits a Seller in a commercial transaction to obtain more favorable terms from a 
financial institution securitizing a receivable due the Seller. 

It is a further object of the present invention to provide a system and method 
that reduces the origination and transaction costs associated with factoring or 
securitizing a commercial transaction receivable. 
15 It is an object of the present invention to provide a system and method for 

analyzing a receivable resulting from a commercial transaction to provide a 
quantitative indication of the quality of the receivable. 

It is still further object of the present invention to assign a standardized 
"score" to one or more receivables resulting from a commercial transaction. 
20 It is another object of the present invention to provide an electronic data 

processing system and method that facilitates reduction in the days sales outstanding 
(DSO) of a Seller. 

These and other objects are achieved in the present invention through the 
provision of an electronic data processing system that is connected with and receives 
25 information from a plurality of data processing systems disposed at one or more of a 
Buyer's, Seller's and Carrier's locations. A software agent is provided to interface to 
the Buyer's, Seller's or Carrier's data processing systems and operates to extract 
commercial transaction data in real-time or near real-time from the data processing 
systems. This data is forwarded, preferably in electronic form, to the electronic data 
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processing system of the present invention, where it is further processed, analyzed, 

reconciled, and scored to achieve the above objects. 

The present invention overcomes the problems noted above, and provides 

additional advantages, by providing a method and system for providing to commercial 

5 market participants a dedicated data processor for consolidating and expediting a 

financial settlement system. A method in accordance with an exemplary embodiment 

of the invention is performed by connecting, over a common computer network, a 

plurality of, Buyers, Sellers, Carriers and Financial Institutions, each connected to the 

dedicated data processor. Upon the placement of a commercial transaction order, all 

1 0 of the various transaction documents such as the PO, CO, INV, BL and POD are 
transmitted to the data processor of the present invention in electronic format and 
stored in a suitable database. It should be understood that any of these documents 
may initially be non-electronic in format and will be converted into suitable digital 
forms for processing by the data processor. This conversion is done either by the 

15 receiving party, or by a call center associated with the processor. Following delivery 
of the goods to the Buyer, the Carrier generates a POD and transmits this to the Seller, 
which is thereafter forwarded to the data processor of the present invention. At this 
point, all transaction documents are consolidated within the data processor database of 
the present invention. Following auditing and reconciliation by the data processor of 

20 all transaction documents, the processor may transmit authorization to the respective 
financial institution to credit the accounts of the Carrier and Seller. The Buyer may be 
either immediately debited, debited after a predetermined period of float, or normally 
invoiced so that the above system appears invisible to the Buyer, depending upon the 
terms of trade. This method of consolidating and expediting the financial settlement 

25 system greatly reduces the administrative costs associated with the accounts 

payable/accounts receivable process for all parties. Further, the present invention can 
be used to reduce or eliminate float for the Seller and the Carrier, thus enabling those 
parties to maximize use of their funds. 

30 BRIEF DESCRIPTION OF THE DRAWINGS 
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The present invention and its resulting advantages can be more fully 

understood by reading the following Detailed Description in conjunction with the 

accompanying drawings, in which: 

FIG. 1 is a block diagram of a commercial transaction system the present 

5 invention; 

FIG. 2 is one embodiment of a dedicated data processor of the present 
invention; 

FIG. 3 is an operation block diagram illustrating the operation of the system of 
the present invention; 

1 0 FIG. 4 is a block diagram illustrating one embodiment of a business process 

layer of the present invention; 

FIG. 5 is a block diagram illustrating one embodiment of a data presentation 
layer 42 of the present invention; 

FIG. 6 is a block diagram illustrating a method for financing an account 
15 receivable in accordance with the present invention; and 

FIG. 7 is a flow chart illustrating a method of quantitatively scoring the value 
of a receivable of the present invention. 



DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
20 Referring now to the Figures and particularly to Figure 1, there is illustrated a 

block diagram of a commercial transaction system generally designated by the 
numeral 10 including a plurality of market participants. Principal market participants 
include a Buyerl2, a Seller 14, a Carrier 16, and a Financial Institution 18. Each of 
the Seller 14, Carrier 16, and Financial Institution 1 8 are connected via data 
25 communications lines 20 to a dedicated data processor 22 of the present invention 
over a computer network such as the Internet. In addition to connectivity of several 
market participants over the computer network, the Buyer and Seller are preferably 
connected to each other either by electronic means 24, or by any suitable non- 
electronic means such as in-person, telephone, facsimile, postal service, etc. 
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The Seller 14 and Carrier 16 each typically include enterprise resource 
planning (ERP) programs (or similar functional application systems) 26 and 28 which 
permit the storage and manipulation of internal business information. Examples of 
typical ERPs include those sold under the trademarks SAP, JD Edwards, and BaaN. 
5 ERPs are often constructed to include a variety of different software systems, which 
may or may not be synchronized or linked together on the Seller or Carrier's system 
or site. Each ERP 26 and 28 further includes databases 29 and 30, respectively, for 
storing information relating to commercial transactions. Associated with the data 
processor 22, data acquisition agents 32 and 34 are provided at the Seller 14 and 

10 Carrier 16, respectively for retrieving and transmitting transaction information relating 
to specific commercial transactions from the databases 29 and 30 to the data processor 
22. Preferably, data acquisition agents 32 and 34 operate to convert transaction data 
in databases 29 and 30 from any one of a predetermined number of commercial 
database formats into extensible markup language (XML) for secure transmission to 

1 5 the processor 22 over the network. 

In order to maintain the confidentiality of the transaction data while being 
transmitted over the network, several layers of protection are preferably utilized. 
First, each party to the commercial transaction is provided with at least one digital 
signature. Digital signatures are well known in the art of data protection as a means 

20 for authenticating the identity of the various participants when information is shared 
between two parties. Upon conversion into XML format, the transaction data is 
signed with the digital signature of the transferee to ensure that the data does in fact 
originate with the transferee. Further, the data and combined digital signature are 
encrypted using conventional private key encryption so as to prevent dissemination of 

25 the transaction data to unauthorized parties. By both digitally signing and encrypting 
the transaction data prior to transmission, the data is both authenticated as to its source 
and protected from unauthorized access. 

Referring now to Figure 2, there can be seen one embodiment of the dedicated 
data processor 22 of the present invention. Data processor 22 preferably includes a 

30 plurality of processing layers for performing specific tasks in accordance with the 
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present invention. A data acquisition layer 36 provides for the acquisition of the 
converted XML transaction data from agents 32 and 34. Data acquired by the data 
acquisition layer 36 is decrypted, authenticated and archived in at least one database 
38 for subsequent use by the processor 22. Further, the data acquisition layer 36 also 
5 parses out the information contained in the transaction data so as to populate a variety 
of fields in the database 38 relating to a particular transaction document. In this 
manner, the database 38 stores both a raw unparsed copy of the received transaction 
data as well as a parsed copy which is acted upon by processor 22. In addition to 
receiving transaction data, the data acquisition layer 36 also operates to securely 
10 transmit several items of summary analytical level transaction data to the Seller 14, 
upon receipt from the Carrier 16. 

A business process layer 40 provides for the processing of the acquired data by 
a variety of software implemented business rules and workflow processes. In 
addition, a data presentation layer 42 provides for the presentation of information 
15 related to the processed data to various individual members of the market participants 
over the computer network. Further, a message bus 43 provides messaging 
capabilities between the data processor 22 and the various market participants 
connected to the processor 22. Specific features of the business process and data 
presentation layers 40 and 42 will be discussed in more detail below with respect to 
20 the operation of the system of the present invention. 

Referring now to Figure 3, there is shown a block diagram illustrating the 
operation of the system of the present invention. In operation, Seller 14 receives a 
purchase order (PO) 44 for goods from a Buyer 12 either electronically or through 
conventional means such as over the telephone or via facsimile. Once a PO 44 is 
25 received, a sales order (SO) 46 is generated by the Seller 14 and input into the Seller's 
ERP and database 29. Agent 32 subsequently converts the SO 46 into XML, signs the 
data with the Seller's digital signature, encrypts the data with the Seller's private key 
and securely transmits the data to the data processor 22. Once received by the 
processor 22, the data acquisition layer 36 decrypts and authenticates the SO 46, 
30 archives both a raw version as well as a parsed version of the SO 46 into the database 
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38. Following generation of the SO 46, the Seller generates a confirmation order 
(CO) 48 for delivery to the Buyer 12. As is known in the art, the CO 48 mirrors the 
received PO 44 and informs the Buyer 12 of the availability and terms of sale of the 
requested items. CO 48 is electronically stored in database 29 in the manner 
5 described above. Agent 32 then subsequently retrieves the CO 48 from the database 
29 and transmits it to the database 38 of the processor 22. 

Following fulfillment of the PO (as evidenced by CO 48 in database 38), the 
Seller 14 then tenders the goods to the Carrier 16 and generates a bill of lading (BL) 
50 for attachment thereto. BL 50 is entered into database 38 in the manner described 

10 above. Carrier 16 delivers the goods to the Buyer 12 and generates a proof-of- 

delivery (POD) 52 indicated either acceptance of the goods or acceptance of the goods 
with exceptions. The POD 52 is then transferred to database 38 in accordance with 
the present invention. Upon generation of an Invoice, the Seller opens an account 
receivable, anticipating payment by the Buyer 12. It should be understood that 

15 numerous additional documents such as an advance shipping notification (ASN), an 
invoice (INV), and a receiving ticket (RT) may be generated by the Buyer 12, Seller 
14 or Carrier 16 in accordance with general business practices. These additional 
documents may be stored in the database 38 for use in ensuring error free processing 
of the transactions. In addition, upon final payment or non-payment by the Buyer, the 

20 account receivable is closed, thereby indicating that the commercial transaction 
between the parties has been concluded. 

Typically in commercial transactions of goods, the Buyer 12 is given a 
specific term in which it must pay the Seller the amount due for the delivered goods. 
Common examples of terms of payment include net 30 days and 2/10 net 30 days. 

25 From the Buyer's standpoint, the time between delivery of the goods and payment to 
the Seller is called float and has a given positive value to the Buyer. In other words, 
the longer the Buyer can go between delivery and payment, the longer it maintains 
possession of the payment amount, thus increasing its value. Conversely, the time 
between delivery and payment from a Seller's standpoint is called day sales 

30 outstanding (DSO) and has a negative value to the Seller. DSO refers to the time it 
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takes for a receivable to be paid by the Buyer. Since most large Sellers typically 

borrow against their receivables in some manner, a large average DSO forces the 

Seller to pay more interest on the loan secured by the receivable. Reducing the DSO 

by facilitating settlement of the transaction thus results in considerable savings to the 

5 Seller. 

In accordance with the present invention, inconsistencies between any two or 
more documents stored in database 38 of processor 22 are identified in substantially 
real-time as the documents are sequentially saved in the database. For example, upon 
entry of both a CO 48 and a BL 50, the common terms contained in both documents 

10 are reconciled to determined whether errors have been made in the preparation of the 
either document. This reconciliation process is carried out at every stage of the 
transaction, thus verifying the accuracy of all data across the various document types. 
In addition, during the document collection process, certain documents take 
precedence over other documents. This eliminates confusion on the part of the system 

1 5 regarding a reconciliation of two contrary documents, without relying upon a 

confirming third document. For example, a CO is precedent to a BL. Therefore, if 
during reconciliation, the terms of the stored CO and BL differ, the CO (dependent on 
the terms of sale and general business practices) is given precedence and an exception 
to the BL is generated to the Seller. This allows the Seller to rectify the error in the 

20 BL prior to tendering the order to the Carrier, thus increasing the likelihood that final 
settlement of the account receivable will be successful. General business practices are 
used to determine which documents in the supply chain process take precedence over 
which other documents as readily understood . The reconciliation process of the 
present invention virtually eliminates the possibility of error, thus reducing the DSO 

25 and greatly increasing the value of the account receivable. 

In practice, the DSO is generally driven by two factors: 1) exceptions in the 
transaction process which take time to resolve; and 2) slow paying Buyers intent on 
maximizing float for their own benefit. By drastically reducing the time taken to 
resolve exceptions in the transaction process, the first of these factors in virtually 

30 eliminated, thus reducing average DSO for the Seller. Further, by allowing a Seller to 
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specifically identify which of its customers pay on time, which of its customers have 
legitimate exceptions, and which of its customers are simply slow payers, the Seller is 
better able to modify its business strategies to maximize the value of the receivable 
and reduce the DSO. 

5 Referring now to Figure 4, there is shown a block diagram illustrating one 

embodiment of a business process layer 40 of the present invention. Upon the 
collection of at least two documents into the database 38, business process layer 40 of 
processor 22 initiates a reconciliation engine 54 to reconcile the information contained 
in the various documents in order to determine if errors or exceptions have occurred 

10 and need to be resolved. The reconciliation engine 54 includes two sublevels of 

processing capability, a rules engine 56 and a workflow processing engine 58. The 
rules engine 56 includes a variety of rules 60 associated therewith which govern the 
method in which transaction document information is reconciled. For example, a 
given rule might ask whether the ship-to address on the CO and the ship-to address on 

15 the BL are identical. If the addresses match, the rules engine 56 indicates that these 
values are reconciled and an exception is not entered. However, if the two addresses 
do not match, the rules engine generates an exception and invokes the workflow 
processing engine 58. It should be noted, that all rules 60 do not necessarily match 
the information contained in the various documents. Rather, the rules 60 are 

20 formulated on the basis of established business principles to determined whether an 

exception should be generated. An example of a particular rules engine capable of use 
with the present invention is the Blaze Advisor Rule Engine sold by Blaze Software, 
Inc. of Mountain View, California. 

In accordance with one embodiment of the present invention, the rules engine 

25 56 is customizable by a specific system customer. In a Seller oriented model, rules 62 
specific to a particular Seller may be implemented throughout the rules engine in 
order to more accurately assess the likelihood that a particular receivable (or class of 
receivables) will be paid within the terms of payment. Similarly, the system customer 
(e.g., the Seller) may indicate that specific rules should apply to specific customers of 

30 the customer (e.g., Buyers). This enables the customer to implement rules relating to 
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specific customers which have been developed based upon a previous business history 
with the customer. The remainder of the rules 60 implemented in the rules engine 56 
are default rules provided by the system operator. In general, it is preferred that at 
least 80% of the rules 60 in the rules engine 56 be default rules provided by the 
5 system operator and that 20% or less of the rules 62 be submitted or customized by 
the customer. This reduces the necessary work on the part of the customer and 
enhances "off-the-shelf operation of the system. 

In the event that an exception is generated by the rules engine 56, the 
workflow processing engine 58 is invoked as a means for resolving the exception. 

1 0 The workflow processing engine 58 includes a variety of workflow processes 64 
operable to respond to the various exceptions generated by the rules engine 56. 
Preferably, each possible exception has an associated workflow processes, although it 
is contemplated that several exceptions may activate a single workflow process. 
Essentially, each workflow process reacts to an exception by providing and 

1 5 implementing a plan of action designed to resolve the exception. For example, upon 
receiving an indication that the ship-to-address on the BL does not correspond to the 
ship-to address on the CO, an associated workflow process 66 is invoked. A first step 
68 of the workflow process 64 may be to send a message 70 through the message bus 
43 to an accounts receivable (A/R) personnel member 72 indicating the disparity and 

20 asking for a response on how to resolve the issue. The workflow process 66 may then 
invoke a time-out procedure 74 providing that, if a suitable response is not received 
from the A/R personnel in a predetermined time period, a message is sent to a higher 
level individual 76. The workflow process 66 would continue to act to provide a 
resolution to the exception until a termination point 78 had been reached. Absent a 

25 suitable response to all resolution queries at the termination point 78, workflow 

process 66 would not reconcile the documents and a flag would be maintained for the 
particular transaction, indicating that at least one document had not been reconciled. 
However, upon receiving a response 80 capable of resolving the exception, the 
workflow process 66 modifies the information in the database 38 in accordance with 

30 the resolution and removes the exception. At this point, the workflow process 66 is 
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ended and the business process layer 40 of processor 22 returns to the rules engine 56 

for invocation of the next rule 60. Each of the actions taken by the workflow 

processing engine 58 is tracked by the processor 22 so as to provide a fully auditable 

trail of the actions taken in response to a determined exception. Once the rules engine 

56 has determined that no exceptions exist, the value of the receivable is limited only 

by the likelihood that the Buyer will be a slow payer. 

Referring now to Figure 5, there is shown a block diagram illustrating one 
embodiment of a data presentation layer 42 of the present invention. Data 
presentation layer 42 includes at least one software application 82 which permit users 
of the system 10 to create and view reports relating to the information stored in the 
database 38. Preferably, the software application 82 is an Internet portal application 
which permits users to access data reports 84 relating to their specific transactions 
over the Internet. An example of a suitable Internet portal application is the Brio 
ONE infrastructure sold by Brio Technology of Palo Alto, California. Examples of 
suitable reports 84 generated and viewed through the application 82 include sortable 
lists of orders and transactions, a detailed description of the current stage in the 
settlement and reconciliation process of a particular transaction including the total 
number of exceptions, as well as the type and severity of each exception. 

In a broader perspective, authorized parties will be able to access a vast 
number of analytical analyses of the data based upon business history of a Seller, 
overall or with respect to a particular Buyer, developed through the systematic input 
of transaction information into the database 38. One example of such an analysis is a 
breakdown of average DSO by Buyer. Information such as this allows the Seller to 
more easily determine the course of business in both broad terms and with respect to 
particular Buyers. 

It should be noted that, since transaction information is continually input into 
database 38, the scope of the reports generated by the application 82 may be 
automatically updated at predetermined intervals. This prevents the information 
contained in the reports from becoming stale, thereby reducing the overall value of the 
report information. 
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In one preferred embodiment of the data presentation layer 42, the internet 

application 82 is provided with a hierarchical certificate authentication system 83. 

Such authentication systems permit access to varying degrees of information between 

different individuals. In other words, rather than disseminate all available information 

5 on a customer-by-customer basis, a hierarchical certificate scheme 83 permits the 

system to differentiate between user authorization levels down to various individuals 

that work for the same customer. For example, a A/R customer service representative 

should be able to access certain specific reports relating to transactions under their 

control, but should not be able to access the cross-buyer analytical information or 

1 0 company history profile. However,the Chief Financial Officer of the Buyer should 
certainly have access to the full variety of reports. The hierarchical certificate 
scheme permits varying levels of access within the same organizational structure. 

Referring now to Figure 6, there is shown a block diagram illustrating a 
method for financing an account receivable in accordance with the present invention. 

1 5 As disclosed above, a Financial Institution 1 8 is preferable connected to the data 

processor 22. As is well known in the art, a large number of Sellers 14 in commercial 
transactions desire to accelerate the effective payment of their receivables by selling 
the receivable to the Financial Institution 1 8. For a percentage of the receivable, the 
Financial Institution 1 8 buys the receivable from the Seller, either on a transaction by 

20 transaction basis (i.e., a factoring arrangement) or on a quasi-permanent basis (i.e., a 
securitization agreement). The percentage involved reflects the desired amount of 
profit on the part of the Financial Institution as well as the degree of risk associated 
with the receivable, and the cost of originating the program which requires analysis 
the relevant data and determining the risk factor. 

25 Because the commercial transaction system 10 of the present invention 

increases the likelihood that a receivable will be paid within the terms of payment, the 
Financial Institution 1 8 may choose to utilize this capability to determine the risk 
associated with a given factoring or securitization program. Because the likelihood of 
in term payment is increased and because the system 10 has absorbed the costs of 

30 acquiring and analyzing the relevant data, the Financial Institution 1 8 is able to 
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increase the profitability of the financing operation as well as decrease the percentage 
rate withheld from the Seller upon transfer of the receivable. This aspect of the 
present invention is referred to as the Financial oriented model. 

Similar to the Seller oriented model discussed in detail above, the system 10 
5 includes data acquisition agents 84 and 86 provided at the Seller's and Carrier's ERPs, 
respectively. Each agent 84 and 86 securely transmits transaction information 
between the parties and a data processor 88. A data acquisition layer 90 at the 
processor 88 receives the data and populates a database 92 accordingly. A business 
process layer 94 at the processor 88 invokes a rules engine 96 and a workflow 

10 processing engine 98 to systematically reconcile transaction information as it is 

received into the database 92. Unlike the Seller oriented model described above, the 
Financial oriented model does not permit Seller customization of rules engine 96. 
Rather, the reconciliation rules are strictly governed by the Financial Institution 18 in 
an effort to standardize the reconciliation process between different Sellers. Further, 

1 5 because the system 10 is operated by a trusted third party, the risk that the Seller is 

financing fraudulent receivables is eliminated, thereby reducing the likelihood that the 
receivable will not be paid. 

In addition to standardizing the reconciliation process, the processor 88 also 
includes a scoring engine 100 which provides for quantitative risk assessment of each 

20 receivable or defined group of receivables. Referring now to Figure 7, there is shown 
a flow chart illustrating a method of quantitatively scoring the value of a receivable of 
the present invention. The scoring process is initiated in step 700 by the completion 
of the goods reconciliation or in step 702 by the lack of reconciliation by the rules and 
workflow processes engines 96 and 98. In other words, scoring of the receivable is 

25 completed following reconciliation of the POD or a corresponding time-out of a 

critical exception. Although multiple shipments may result from a single PO, each 
shipment is scored separately. This is because each path represents the lowest level of 
granularity in a given transaction. The following tests are conducted on the 
transaction data for use in the scoring process. 1) Field Population Test; 2) Critical 

30 Data Test; 3) Data Element Validation Test; 4) Data Transportation Test; 5) 
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Document Count Test; 6) Terms and Conditions Test; 7) Goods and Services 

Validation Test; 8) Invoice Validation Test; 9) Freight Invoice Validation Test; 10) 

Number of Open Critical Exceptions Test; and 1 1) Number of Open Problematic 

Exceptions Test. 

5 Field Population Test 704 : All transaction documents are pulled in and a null 

field test is run. This test determined whether the data elements required for 
reconciliation of each document are present in the database. If any data is missing 
then the document score will be increased by "1" for each item of data missing. Each 
document will have the score appended to the document. The overall shipment score 

1 0 will be the sum of the shipment document scores. 

Critical Data Missing Test 706 : All transaction documents are pulled in and 
the null field test is run against the critical data elements. The same data elements 
used in reconciliation will be checked for each document. If the data is missing then 
the document score will be increased by "1". Each document will have the score 

1 5 appended to the document. The path score will be the sum of the path document 
scores. Essentially, this tests gives greater weight to critical data elements. The 
definitions of the various critical data elements are predefined by the system 10. 

Data Element Validation Test 708 : All transaction documents are pulled in 
and a table is created which compares data elements for each document types. Each 

20 data element that is present, but apparently meaningless will increase the document 
score by "1". 

Data Transposition Test 710 : All transaction documents are pulled in and a 
transposition test is run. The same data elements used in reconciliation will be 
checked for each document comparison. If there is a conversion error then the 
25 document pair score (i.e., the combines score of each of the documents involved in the 
conversion) will be increased by "1". Each document will have the pair score 
appended to the document. The shipment score will be one half the sum of the 
shipment document pair scores. 

Document Count Test 712 : All transaction documents are pulled in and the 
30 count is taken per shipment. The document count for a given path covers the SO, CO, 
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ASN, INV, and the POD for a total of five documents. Therefore for each ASN 
against a sales order the count will be five if correct and a negative one for everyone 
that is absent. 

Terms and Conditions Test 714 : Pull in the CO, ASN and INV and determine 
5 whether the INV correctly applies the terms and conditions agreed to in the CO. If 

terms are net 30 days for the product does the INV reflect that payment is required 30 
days after the invoice date. Also, has the product been shipped as stated in the CO 
promised date and ASN actual ship date and has the partial shipment request been 
honored? If there is compliance than it is indicated by appending the words "In T&C 

10 compliance" to the invoice or "Not in T&C compliance". The score increments "1" 
for each of wrong payment required date, late shipment, and a partial shipment where 
partial was not allowed. 

Goods and Services Validation Test 716 : Pull in the CO, ASN and the INV. 
Through comparison of the line detail of the CO and the detail of the ASN determine 

1 5 whether the goods ordered were the goods shipped. Also determine whether it was 
these goods that were invoiced and in the quantity specified on the ASN. If these 
items are validated then append to the invoice "goods validated". If these are not 
validated then appended to the invoice "goods invalid." The score is incremented by 
"1" for the wrong SKU (i.e., product number, description, quantity in excess of CO 

20 line quantity.) 

Invoice Validation Test 718 : Pull the CO and the INV and compare the line 
item unit price, total price (proportional / rounding error), and tax (proportional / 
rounding error). If there is agreement between these items on each document then 
append to the goods invoice "price valid", versus if not "price invalid." The score 

25 increments by "1" for each wrong unit price, total price, or tax. 

Freight Invoice Validation Test 720 : Pull the BL and the Freight INV and 
compare the line item unit price, total price (proportional / rounding error), and tax 
(proportional / rounding error). If there is agreement between these items on each 
document then append to the goods invoice "price valid", versus if not "price invalid." 

30 The score increments by "1" for each wrong unit price, total price, or tax. 
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Number of Open Critical Exceptions Test 722 : Pull in and count, for each 
shipment, the number of unclosed critical (non-reconcilable) exceptions. Take the 
count and that is the score. Append the score to the ASN. 

Number of Open Problematic Exceptions Test 724 : Pull in and count, for each 
5 shipment, the number of unclosed exceptions less the critical (non-reconcilable) 
exceptions. Take the count and that is the score, append the score to the ASN 

After conducting the aforementioned tests, the scoring engine transmits, in 
step 726, a transaction score relating the results of the various tests. Each tests score 
is positioned side by side to form at least an 1 1 digit number. Comparison of this 
10 number with predefined risk allocation tables in step 728 permits the Financial 
Institution 1 8 to readily determine the risk of the measure transaction. 

Since a transaction based risk assessment scoring method does not account for 
anomalous transactions, additional steps are undertaken to examine the risk of the 
Buyer, based upon the Buyer's past transaction history. Initially, the scoring engine 
15 1 00, in step 730, obtains a Dunn & Bradstreet credit rating for the Seller. Then, using 
the information contained in the database 88, the scoring mechanism 100 proceeds to 
step 732, where a standard deviation of the Buyer's one year payment against terms 
record is calculated, with respect to purchases from the Seller. This enables the 
Financial Institution to determine whether the Buyer has a recent history of paying in 
20 term. In step 734, the scoring mechanism 1 00 determines the Buyer's average dollar 
volume per purchase over the past year as well as the fluctuation in the profile of this 
dollar volume. In step 736, the scoring mechanism 100 determines an historical 
average dollar volume of active and unclosed (i.e., unpayed) transactions and its 
corresponding profile. In step 738, the scoring mechanism 100 determines a present 
25 dollar volume of active and unclosed transactions. This Buyer specific scoring 

information supplements the transaction specific scoring information and enables the 
Financial Institution to better allocate the risk in the investment. 

While the foregoing description contains numerous details, it is to be 
understood that these are provided for purposes of explanation only, and that these 
30 details are not to be read as limitations of the present invention. The specific 
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exemplary embodiments described above can be modified in many ways without 
departing from the spirit and scope of the invention, as defined by the following 
claims and their legal equivalents. 
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We claim: 

1 . A method of reconciling a commercial transaction for the sale of goods 
between a buying party and a selling party using an electronic data processing system 
comprising the steps of: 

receiving purchase order information from the buying party identifying at least 
one item to be received from the selling party; 

storing said purchase order information in said electronic data processing 

system; 

receiving bill of lading information from the selling party identifying at least 
one item to be provided to a carrier for delivery to the buyer in response to said 
purchase order information; 

storing said bill of lading information in said electronic data processing 

system; 

receiving proof of delivery information from said carrier identifying at least 
one item delivered to the buying party by said carrier; 

storing said proof of delivery information in said electronic data processing 

system; 

comparing at least two of said purchase order information, said bill of lading 
information, and said proof of delivery information using said electronic data 
processing system to generate reconciliation information indicating whether said at 
least two of said purchase order information, said bill of lading information, and said 
proof of delivery information are reconciled; and 

storing said reconciliation information in said electronic database processing 

system. 
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